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ABSTRACT 

In the beginning of the fiscal year 1992, 
the development organizations of Johnson 
Space Center (JSC) were poised to begin 
two major projects: the Space Station Con- 
trol Center and the refurbishment of the 
telemetry processing area of the Space 
Shuttle Mission Control Center. A study 
team established that a common front end 
concept could be used and could reduce de- 
velopment costs for both projects. A stan- 
dard processor was defined to support most 
of the front end functions of both control 
centers and supports a consolidation of 
control positions which effectively reduces 
operations cost. This paper defines that 
common concept and describes the progress 
that has been made in development of the 
Consolidated Communications Facility 
(CCF) during the past year. 

mission control, ground control, telemetry 
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1 BACKGROUND 

In preparation for ground support of the 
upcoming space station, Johnson Space 
Center had begun to plan a construct a 
Space Station Control Center (SSCC). A 
building adjacent to the Mission Control 
Center (MCC) was in construction and re- 
quirements had been written. At the same 
time, development efforts in the MCC had 


been refocused to replacement of the oldest 
and least reliable machines, those of the 
front end. A study team was established 
to determine if there was merit in a joint 
development effort of a common design. It 
was hoped that such an effort would reduce 
both development and recurring costs. 

1.1 Three-Layer Model 

The study began by defining a model of the 
front end functions. A three layer view of 
the processing was produced and is dia- 
grammed below. 



Figure 1 . Three layer view of the front end. 


Layer 1 is that processing which terminated 
the ground-to-ground protocol and inter- 
faced with the external world. The God- 
dard Space Flight Center (GSFC) commu- 
nications network protocol is handled in 
this layer, thereby isolating the remainder 
of the control center from any changes in 
ground network. 
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Layer 2 provides the source specific pro- 
cessing for the front end. This layer does 
the specific format manipulation based on 
variations in spacecraft communications. 

It, in turn, isolates any changes in space- 
craft telemetry from any other areas of the 
control center. 

The final layer, layer 3, formats the data so 
that it can be distributed to the remainder 
of the control center. Ideally, the format is 
identical despite the spacecraft. This al- 
lows common applications, such as display 
building programs, to use and understand 
the data independent of source. 

Each processing layer removes data for- 
matting variation such that the entire front 
end produces a set of data which is identi- 
cal despite its source. An application can 
use the data from any spacecraft without 
modification to its processing code. This 
provides an excellent opportunity for dupli- 
cation of several applications downstream 
of the front-end processing. Additionally, 
future support for additional spacecraft be- 
comes easier. 

1.2 Layers vs. Requirements 

This model provided an excellent frame- 
work against which to map the require- 
ments of the shuttle and space station pro- 
grams. In the mapping of these functions, 
layer 1 was designated the institutional 
layer. It contained the demultiplexers and 
modems that receive the data from external 
world. It also included the recording, 
switching and routing functions. It in- 
cluded the processing to handle the ground 
network data which included data from 
other NASA sites, network scheduling and 
network status data processing. The re- 
quirements for the space station and shuttle 
data processing revealed that the layer 1 


functions were identical for both programs. 

Layer 2 isolated most of the differences 
between the spacecraft telemetry. The 

space station telemetry consists of CCSDS 
packets using Reed-Solomon encoding. Its 
telemetry object lists are nonperiodic. The 
shuttle telemetry could require decryption, 
and utilizes Inter-Range Instrumentation 
Group (IRIG) standards. It's periodic na- 
ture is key to validating and decommutating 
the data. It became clear in mapping the 
requirements for this layer that the two 
programs were completely different. How- 
ever, if the unique processing could be 
isolated, it appeared that a synergistic ap- 
proach to the front end could be achieved. 
Spacecraft unique processing of the data 
could be performed on a single type of ma- 
chine. Using a single platform, even with 
a different configuration of boards, would 
allow a synergistic approach to the mainte- 
nance and operations of the machines. 

Once the data has been extracted from its 
down link format, layer 3 provides distri- 
bution of that data to the other areas of the 
control center. Development of a common 
data format provides the potential that the 
data acquisition functions used to receive 
the data throughout the control center can 
be identical and additional synergistic sav- 
ings can be created. The code to perform 
layer 3 functions for the shuttle telemetry 
differ somewhat from that of the space sta- 
tion program, but both sets of code can 
easily run on the same platform. 

The diagrams below illustrate the allocation 
of the control center requirements to the 
three-layer model. 
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Correspondingly, the uplink function was 
mapped in reverse— building outbound 
commands in a layered fashion. The basic 
elements of these layers are given in the 
Figure 3. Once again, it is apparent that 
the functions are parallel and that the 
programs could benefit from synergism. 

1.3 Considering the Marketplace 

The study team evaluated the requirements 
and did an initial survey of the market- 
place. A straw-man architecture in which 
the front-end processor was a VME-based 
machine was proposed. Specialized boards 
to do the spacecraft-unique processing were 
found to be available that would run on 
such a platform. An estimate for a com- 
mon front end for both control centers at 


JSC determined that NASA could save 15% 
of the estimated development costs and re- 
duce the maintenance staff by 30. Some 
savings result from the use of a single piece 
of hardware for both programs. Some 
savings is due to the single development 
effort on common platforms customized for 
each program. The results of this study 
were used to launch the Consolidated 
Communications Facility (CCF) project. 
This was approximately one year ago. 

2. CURRENT STATUS 

Since that time, the requirements for the 
consolidated system have been written and 
the project has been divided into 5 subsys- 
tems. These were: the Consolidated Data 
Select Switch (CDSS), the Consolidated 
Data Recording Subsystem (CDRS), the 
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Front End Processor Subsystem (FEPS), 
the Consolidated Distribution Subsystem 
(CDS) and the Test and Checkout Subsys- 
tem (TCS). Each of these subsystems has 
been designed and procurements are in 
progress, A mapping of the subsystems to 
the layered concept is shown below. 


2. 1 Consolidated Data Select Switch 
(CDSS) 

The CDSS consists of high-rate and low- 

rate data switching, accepting multiple data 
lines from external sites and routing data to 
external sites. The low rate data switch 



Figure 4. A mapping of the CCF components to the three-layer model. 
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handles the majority of this work-it is 
currently specified as a 600x500 port 
switch. The Request For Proposal (RFP) 
for this switch is being developed. The 
high rate data has few lines and will be 
patched rather than switched, 

2.2 Consolidated Data Recording Subsys- 
tem (CDRS) 

The planned CDRS technology is borrowed 
from the television industry which keeps 
commercials on cassettes. A robot then 
queues the tapes automatically and plays 
them as scripted. The control center taping 
system is envisioned as two sets of roboti- 
cally operated tape silos. Since recorders 
do not operate efficiently at the slow data 
rates of the control center, data will be 
buffered and sent to the recorders in bursts. 
The recording system is expected to be run 
with minimal operator intervention. The 
operator will be needed only to remove any 
tapes for permanent storage or to arbitrate 
playback capability. This approach will re- 
duce operations costs— a strong theme in 
the development of the CCF. 

2.3 Front End Processing Subsystem 
(FEPS) 

The FEPS contains the bulk of the process- 
ing in the CCF. The current design of the 
Mission Control Center contains several 
specialized hardware devices designed in 
the sixties and seventies. Over the years, 
other systems based on more modem COTS 
technologies have partially replaced the 
front end processing capabilities, but never 
were able to completely do so. The result 
is that the Mission Control Center now has 
four different design approaches to the 
telemetry processing. All will be replaced 
with the CCF. 

The design of the CCF FEPS is based on a 


single VME-based machine. The machines 
will be tailored to suit the specifics of the 
spacecraft data for which it is used with 
special processing boards and software. 

The FEPS do all of the layer 2 processing. 
This isolation of the layer 2 to a single pro- 
cessor means that the CCF could be ex- 
panded to handle future vehicles with 
change only in the FEP processing. Addi- 
tionally, the FEPS provide the processing 
platform to create the common data format 
discussed in layer 3. The procurement for 
the FEPS is currently in progress; replies to 
the RFP are due in January. 

2.4 Test and Checkout Subsystem (TCS) 

The TCS will run on the FEPS platform 
and will provide the ability to run test data 
streams through the system and score the 
output to assure proper processing. The 
TCS will be run routinely to validate the 
hardware and software is ready. It will 
also be used by maintenance personnel to 
locate problems. 

2.5 Consolidated Distribution Subsystem 

The CDS provides distribution of the data 
to the computation and display systems 
throughout the control center complex, in- 
cluding the older IBM mainframes and the 
newer UNIX workstations. Because the 
format of the data is common in nature for 
both programs, a single display processor 
can be used for either shuttle or space sta- 
tion data. This basis for the front end out- 
put simplifies the consolidation of the re- 
mainder of the control centers for each 
program. 

3 SUMMARY 

By looking at ground support for a joint 
space station and shuttle project, NASA has 
found a better and cheaper way of provid- 
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ing a telemetry processing area. The defi- 
nition of a front end concept and mapping 
the functions required by both the shuttle 
and space station programs clarified the 
needs of each program. From this, NASA 
was able to determine what common hard- 
ware and software could support both. The 
subsystems were defined and designs done 
to accommodate the needs of both pro- 
grams, as well as expand to future. The 
procurement of much of the CCF is cur- 
rently in progress and the entire project is 
expected to be complete in 1996. 
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